A couple of weeks ago I published my first Android App Surgery, a technical review of MySettings from JQSoft. One of my UX suggestions was that they drop the "Exit" menu item. This turned out to be more controversial than I expected and soon dominated the discussion in the comments.
So, when should your app include an exit button?
The Short Answer
Never.
The Long Answer
Your app doesn't need an exit button. It really doesn't. Arguments to the contrary can generally be summarized as:
Let me posit this assertion: no they don't.
Of the apps that ship with the device (Gmail, Contacts, Maps, Gallery, etc.) exactly none of them include an exit button, and most users are comfortable with that. Nonetheless many developers are adamant, "I added it after users demanded it!".
Fair enough, so why do some users demand an exit button? How do they cope with the bundled apps without an exit button? In my experience what they really want is:
Many users perceive that an exit button implements this requirement and ask for it to be added. Developers, looking to please their users, obligingly add one. Shortly thereafter they both fail.
Kill Everything When Not in Use
As soon as an app isn't visible its onStop handler is fired, as soon as it's not the foreground Activity onPause is triggered. This happens no matter what the circumstance - including hitting the back or home buttons or selecting a notification.
At this point (ideally within onPause) you should behave as though your user has hit exit. Location and Sensor Listeners should be removed, Services stopped and unbound, and Intent Receivers unregistered.
Once your app moves back to the foreground - triggering onStart and onResume - you hook everything back up.
"Sure," you're thinking, "but what about apps that need to run in the background?"
Foreground Services and Ongoing Notifications
Some applications, such as turn-by-turn navigation and music players, need to run (and use resources like GPS) while invisible. This is generally achieved using a foreground Service. It's also the only reason for creating a foreground Service.
Users should always know if such a Service is running, and be provided with a simple way of unambiguously turning it off when it is. In navigation there's an "exit navigation" menu item. Pausing playback in a music player is enough to kill the playback Service. In both cases ongoing notifications provide a simple shortcut to the app, where you can easily stop the Service.
As far as the user is concerned, if the app isn't visible and there's no notification icon it's not consuming resources. If there's an icon, it's running in the background and I can click the notification to go turn it off.
Background Services and Polling
Some applications (such as News & Weather) need to occasionally run in the background to get updates. Whenever possible use inexact repeating Alarms to schedule your updates, and then kill your service as soon as the update is complete.
This will help with resource use, but is still only half the answer. How can a user demand the app stop using resources completely?
What's the easiest way for me to prevent every app from transferring data?
Settings > Accounts & sync > Background data
Unchecking this should ensure that no app send or receive data while it's not visible. However: This needs to be enforced at an application level - so if this comes as a surprise to you have a fix to implement and an update to go push.
Go ahead, I'll wait.
Offer Users Options
Provided the user is cool with background updates in general, you need to let them adjust the frequency - or disable them - for your app. Be conservative by default. If users aren't getting updates as quickly as they want they'll look for a way to increase the frequency.
Be Adaptive
A Twitter discussion from this post resulted in a suggestion that "Android should offer a way to listen for low battery so that an app can be more conservative with it's use of resources." Register a Broadcast Receiver and thou shalt receive.
You can also monitor for things like connectivity status and type, so you can disable updates when there's no data connection, or modify the frequency based on the connection type.
In each case it's always good practice to offer these tweaks as user configurable options.
Conclusion
If you build an application that's predictable, configurable, and unambiguous your users won't ask for an exit button. The first time they see an unknown background Service that's been running for an hour, or the GPS icon unexpectedly starts flashing, or the device gets hot while in their pocket they're going to get narky.
Next on my hit list: Splash screens, task killers, and modal "loading" dialogs.
So, when should your app include an exit button?
The Short Answer
Never.
The Long Answer
Your app doesn't need an exit button. It really doesn't. Arguments to the contrary can generally be summarized as:
- Users expect it.
- It's a way to let users say "stop doing everything and stop consuming juice".
Let me posit this assertion: no they don't.
Of the apps that ship with the device (Gmail, Contacts, Maps, Gallery, etc.) exactly none of them include an exit button, and most users are comfortable with that. Nonetheless many developers are adamant, "I added it after users demanded it!".
Fair enough, so why do some users demand an exit button? How do they cope with the bundled apps without an exit button? In my experience what they really want is:
An unambiguous way to guarantee that an app will stop consuming resources (battery, CPU cycles, data transfer, etc).The Goggles Do Nothing!
Many users perceive that an exit button implements this requirement and ask for it to be added. Developers, looking to please their users, obligingly add one. Shortly thereafter they both fail.
- In most cases the exit button simply calls Activity.finish. This is exactly equivalent to hitting the back button. Exactly. Services keep running and polling keeps happening. Users may think they've killed the app but they haven't, and soon they'll be even more annoyed.
- Exit behavior is now ambiguous. Should your exit button just close the Activity, or should it also stop all associated Services, Receivers, and Alarms? What should back do? What happens if they hit home instead? What happens if your app has a widget? Should the exit button stop that from updating too?
Users: Consider this. If an app needs an exit button because the back button doesn't properly manage resource use, what do you think the chances are that this exit button will be implemented properly?
Kill Everything When Not in Use
As soon as an app isn't visible its onStop handler is fired, as soon as it's not the foreground Activity onPause is triggered. This happens no matter what the circumstance - including hitting the back or home buttons or selecting a notification.
At this point (ideally within onPause) you should behave as though your user has hit exit. Location and Sensor Listeners should be removed, Services stopped and unbound, and Intent Receivers unregistered.
Once your app moves back to the foreground - triggering onStart and onResume - you hook everything back up.
"Sure," you're thinking, "but what about apps that need to run in the background?"
Foreground Services and Ongoing Notifications
Some applications, such as turn-by-turn navigation and music players, need to run (and use resources like GPS) while invisible. This is generally achieved using a foreground Service. It's also the only reason for creating a foreground Service.
Users should always know if such a Service is running, and be provided with a simple way of unambiguously turning it off when it is. In navigation there's an "exit navigation" menu item. Pausing playback in a music player is enough to kill the playback Service. In both cases ongoing notifications provide a simple shortcut to the app, where you can easily stop the Service.
As far as the user is concerned, if the app isn't visible and there's no notification icon it's not consuming resources. If there's an icon, it's running in the background and I can click the notification to go turn it off.
Background Services and Polling
Some applications (such as News & Weather) need to occasionally run in the background to get updates. Whenever possible use inexact repeating Alarms to schedule your updates, and then kill your service as soon as the update is complete.
This will help with resource use, but is still only half the answer. How can a user demand the app stop using resources completely?
What's the easiest way for me to prevent every app from transferring data?
Settings > Accounts & sync > Background data
Unchecking this should ensure that no app send or receive data while it's not visible. However: This needs to be enforced at an application level - so if this comes as a surprise to you have a fix to implement and an update to go push.
Go ahead, I'll wait.
Offer Users Options
Provided the user is cool with background updates in general, you need to let them adjust the frequency - or disable them - for your app. Be conservative by default. If users aren't getting updates as quickly as they want they'll look for a way to increase the frequency.
Be Adaptive
A Twitter discussion from this post resulted in a suggestion that "Android should offer a way to listen for low battery so that an app can be more conservative with it's use of resources." Register a Broadcast Receiver and thou shalt receive.
You can also monitor for things like connectivity status and type, so you can disable updates when there's no data connection, or modify the frequency based on the connection type.
In each case it's always good practice to offer these tweaks as user configurable options.
Conclusion
If you build an application that's predictable, configurable, and unambiguous your users won't ask for an exit button. The first time they see an unknown background Service that's been running for an hour, or the GPS icon unexpectedly starts flashing, or the device gets hot while in their pocket they're going to get narky.
Next on my hit list: Splash screens, task killers, and modal "loading" dialogs.
Edit: Added a video version of my position.
What about applications that access an account of some sort with private/secure data?
ReplyDeleteExiting might include finalizing a session - I suppose this would then be considering "Logging Out" rather than exiting...
Great post!
ReplyDeleteI'd never heard of getBackgroundDataSetting() before. I'd imagine the vast majority of other devs haven't either. Does it affect anything else, such as NetworkInfo??
It would be good if non-visible apps would receive a NetworkInfo that at least appears to be offline.
How about service-based applications that you don't expect running but you have forgot to close? I have few messengers that run in background and I always get annoyed when I notice GPRS traffic leak because of my non-closure. There are also buggy applications from the market that keep draining battery life when not closed. I'm not quite sure if the task killer is enough for that, I just don't like the 'non-exit' concept.
ReplyDeleteWhat makes you think that a developer who has already made a buggy application will correctly implement the exit button?
DeleteGoogle's official navigation app has an exit button :-0
ReplyDelete"Google's official navigation app has an exit button :-0"
ReplyDelete...which was already addressed in the article. Did you read it?
Mario:
Buggy applications aside, if an app has a background service that is designed to run until explicitly stopped by the user, then it'll have a way to stop it. IM applications have a "log out" button, or something similar, which should do the job of disconnecting and stopping their background services.
@Berdon:
ReplyDeleteExactly. I find it simplest to think of designing Android app flows as if you were designing a Web app. At most, a Web app *might* have a "logout" option, if it is particularly secure, but most sites (and users) tend to rely on an automatic timeout. And many Web apps skip the "logout" process as well.
@Mario Peshev:
What makes you think that developers who write buggy apps will somehow magically be able to write non-buggy "exit" options?
I totally get where this article is coming from, and mostly agree... BUT, I still like that most twitter applications have an exit option especially when I'm evaluating multiple twitter clients. For example, I have Twidroid, Touiteur, and Twitter for Android installed, and depending which one I want to alert me for my updates, it's much easier to tell Twidroid and Touiteur to exit than it is to tell the Official Twitter app to stop polling for updates. Best I could do was set it to once a day, or turn off notifications, which was a lot more detailed than I wanted it to be.
ReplyDeleteTrue, in every day use, I'd never use an exit button in these apps, but it's a very convenient way of telling an app that normally does background polling to stop doing it until I manually launch it again.
@Berdon: everytime you "exit" the application by hitting home or back, the application will call onPause(), you can Override this and log the user out or lock the session when this is called.
ReplyDeleteCheckout "mint.com" from the Android market, and enable the pin lock feature on the settings, I think it's one of the easiest-to-see examples.
@Commons Guy, I just prefer to know that 'exit' exists and to keep track of the KBs from my GPRS package. The non-existence of EXIT makes me unsure of the battery/traffic drain.
ReplyDelete@jrishel - Twidroid is the app in question here. When I omit the "Exit", I usually notice updates and activity later.
@jrishel: When you hit "exit" on those twitter apps, they are just calling Activity.finish() and the pollings will continue since they are probably using the AlarmManager to poll tweets. When an activity calls finish(), the AlarmManager scheduled services don't stop, unless the developer makes it work that way.
ReplyDeleteI disagree. I am a fan of the exit button. Its a way for me to know that the application is done doing whatever its doing, and no background work will happen.
ReplyDeleteFor example, if I had something that tracks my position, but I only wanted it to track me for a short period of time, i want to simply hit "exit" when I am done. It give me peace of mind.
Or what if I want to go to bed, but I want to stop twitter from updating while I am asleep. I don't want to mute my phone... its there for emergencies. I simply want to exit my twitter client.
Users do not want to mess with settings to stop background services from working.
@wjmay: when you click the exit button you are not really exiting the app. The activity "finishes" and its the same thing as hitting the back button, it will do the same thing.
ReplyDeleteAlso, if you want to sleep quitely while still letting your phone ring at night you should checkout Bedside, and if you don't like using your phone as a night clock checkout the included widget.
Excellent read. Thank you. I completely agree.
ReplyDelete> "Android should offer a way to listen for low battery"
ReplyDelete> "Register a (BATTERY_CHANGED) Broadcast Receiver and thou shalt receive."
Is it really worth waking up/starting X number of processes for every single battery change event?
Is there a likelihood of a separate "low battery" broadcast action in future?
Certain apps that run obtrusively or noisily should have a button that assures the user that this activity is going to stop. For instance, after using Google maps navigation to get to my destination, hitting the Exit Navigation button assures me that the app isn't going to scream out that my GPS signal is lost in the middle of a business meeting.
ReplyDelete@John:
ReplyDeleteAs addressed in the article, the Exit button in Google Maps Navigation is to stop the foregroundService. Regular apps do not use foreground services and they stop by themselves.
One App where I would like to see an exit button is the browser. After surfing a while i really don't want to click back a couple of times (and partially reloading the pages, depending on what browser it is) until i know the browser is done. If i just press home i assume it's still taking up memory space to be able to relaunch quickly and it's not properly closed.
ReplyDeleteThis counts for other apps that have a long "back key history". The browser was just the first to come to mind.
Otherwise I agree that there doesn't need to be an exit button
What if your app consists of several screens, and the user is 4-5 screens deep? Having a one click solution (or perhaps two clicks if it's menu -> exit) could provide a better user experience than having them hammer the back button several times.
ReplyDeleteFor the most part, I agree with the article, but there's almost always an exception.
My app allows users to connect and chat on multiple irc servers and uses a foreground service.
ReplyDeleteI have an exit option in the menu, which, when triggered, disconnects from all servers, stops the service, unregisters all receivers and finishes. This is the easiest way for users to completely stop all activity in my app although manually disconnecting all servers and leaving the app will have the same effect.
For my app, I see the exit button as being essential but I'd be interested in hearing how I could replace it.
Al,
ReplyDeleteJust change the "exit" button to "logout" and make sure you have an icon in the notification area and you are in spirit doing what this article advocates. You are doing a foreground service which is discussed.
As far as the browser is concerned, when I'm done I close all the windows I was browsing by bringing up the menu and then Windows. This gets you all the way back to the Google page and you can then press back ONCE and close the browser. Because yes, if you just hit HOME it will continue to keep all the windows you were viewing open and running.
ReplyDeleteFor everything else I use the App Killer...putting the widget for it on your desktop really helps with this. I press it a few times a day. My battery stays charged for a long time and charges really fast, even when plugged into my computer through USB. My husband's is constantly running out because he NEVER uses the app killer.
Use the app killer if you're really worried about it. You can even set it not to kill certain things.
The only thing you really need a quit button for is Pandora. I'm a little annoyed that the music player that comes with the Droid doesn't have one.
I agree with Chnoch. The first thing I thought when I read that there should never be an exit button was that the official browser NEEDS it. Hitting the back button some 10 or so times after a little browsing simply to exit is a bit annoying. If I don't do that and "exit" it some other way like switching to another app with the home button, I later find the browser in the running processes, which debatably seems to slow down the phone one way or another.
ReplyDeleteThis is one significant reason why I use Dolphin Browser, because the menu has an exit while the back button still goes back to the previous page as expected. The process of properly exiting is then trimmed down from several seconds to about 1 second.
For apps that don't have multiple pages to go back through just to exit, then yes, there isn't much point to it. But on the other hand, is it really a big deal if an exit option is included anyway? What I gathered from the article was that it simply isn't needed, instead of being bad design, but worded to make it sound like bad design. Is there a problem having two ways to do the same thing? It is similar to having multiple ways to exit a PC application, which are generally File > Exit, clicking the X, or right-clicking it in the Task Bar and clicking Exit. It also gives more flexibility to the user, allowing them to pick the method that is most convenient or if broken hardware prevents one of the methods. Just because the back-end doesn't need it doesn't mean it's not useful on the front-end for the users.
I released my first app a couple days ago which includes an exit button. This article brought that subconscious design decision into question and I'll put some consideration into removing it, but I don't think it's big enough of a deal to change it when no users complain about the exit button being there.
My two cents.
@Jay: have you ever used the "Home Button" to exit an application? Yes, thats the way to exit out of the app quickly without having to go back too much
ReplyDeletevery good - thanks - especially the getBackgroundDataSetting() stuff
ReplyDelete@Daniel Velazco, I'm pretty sure the app developers of twidroid and touiteur are doing more than just calling finish()
ReplyDeletePerhaps exit is the wrong term? Should they call it "stop notifications and polling until next launch" hard to fit that on button label though :-)
@jrishel:
ReplyDeleteSure, and let's say they are, with that we could say these are the cases of an "Exit" button:
1) Regular Apps: No need of an exit button.
2) Foreground Services: They could use a "Stop Service" button (just like Google Navigation does).
3) Regular Apps with Background Services: I guess "Disable" is the right term to use in the case of Touiteur/Twidroid, and maybe, for the sake of user-friendliness, it might as well just stay as "Exit".
But, we all go back to the same. From the developer's perspective, there's still no need for an "exit" method the way everybody is used to.
Many apps use the back button for in-app navigation. To successfully navigate out of an app, it requires back-tracking through the entire app. Simply hitting the home button is equally inconsistent because of how apps handled the very difference you mentioned between the two methods of exiting an app.
ReplyDeleteMainly, closing and exiting an app are different. For many apps, including web browsers and Google Maps, hitting the home button should pause the experience. Reopening the app should continue the state of the program as it as so if the user were interrupted they can restart.
With exiting, the experience should end so that when the app is started, it is fresh. This is a different experience from before. This is inconsistently accomplished with the back button with some apps one hit of the back button, two hits, complete back-track, or a separate exit option. Essentially, an exit menu option is clear, concise, if implemented consistently would be unambiguous and would allow the user to finish their task differently than if they were interrupted in their task. For a browser, this would clear cache and tabs, for maps it would start the map back at center or home instead of on a previous search, start from a fresh playlist in a music player, etc.
I personally believe all apps should implement an exit menu item. Hitting home should save the state of the app for resuming. The back button is not intuitive or able to be consistently implemented due to in-app usage of the button (back buttons in browsers, previous tracks in music players, undo in editing programs). An OS provided exit button or consistent implementation of an exit button in the menu is my preference as a user.
Great. Almost same suggestion from this site: http://www.meatspin.com
ReplyDelete@Alan, I prefer the 'back' trick when we don't have "Exit", but 'backing' in a browser could take 20+ clicks if you have browsed a lot. Content is also refreshed which is bandwidth related etc.
ReplyDeleteI think the main problem is that users just don't get Android's task and memory management.
ReplyDeleteOften, the only "respected" way to implement "exit" for them is to kill the process, so that nothing will show up in task managers or "running services". Way too many users think any process in memory does use CPU time and blocks free memory, as it does in Windows.
And then the users will complain nontheless that wanted background jobs (like getting new Tweets) aren't working...
Even if you just add some broadcast Intents to your manifest (like SD (un)mount, or audio becoming noisy), people will complain why your app is "running all the time" (was once loaded by Android to deliver the broadcast).
I guess the only reasonable way to fix the problem with "when should services work" (like getting new Tweets) is to offer a schedule plan.
However, some users will always expect exactly what the app isn't doing, like (not) getting new Tweets when the app was left with Home, and they also won't like lots of options (or not even take a look at them)...
Sometimes I wish there was no way for users to see anything system internal but the services actually doing something (i.e. executing code, not only lingering about waiting for new Intents/startServices).
How about a long-click on the back button which would mean 'take me aaall the way back', exiting the application, and resetting the state to default for the next time the app is run?
ReplyDeleteMy biggest problem with the "Don't include an exit" button is functional, not perceptual. I know the Lifecycle of Android applications, and I know that "exit" really isn't. But suppose the following: I'm in an application, lets say, Gmail. I click on a link, it takes me to my browser. I read the link, see something interesting that's continued on page 2 of the article. By the time I'm done reading all 4 pages of this article, I want to go back to my email. So naturally, I hit "Back". Which reloads page 5. And then 4... 3... 2... 1... and once more, oh, there we go, there's my email so I can reply to the person saying "Good read, thanks!". But I suppose I could have just pressed "Home" and loaded gmail again. Or, long pressed "Home" and used the "Recent Applications" window to select gmail again. But none of that seems to me, as the end user, nearly as intuitive as an "Exit" button under the menu. And, oh yea, then the next time I open my browser from my desktop, I'm back where I left it, in the middle of that article, which I wouldn't be if I hit "Back" (assuming it was a one page article). It would instead load my home page under that circumstance... With out an exit button, things are inconsistent. I don't care how that inconsistency is fixed, be it changing behaviors of existing buttons such as back (long press back to do a "super back" which would back you all the way out to the state before the app was "launched"?) or the inclusion of an exit button, it really doesn't bother me. When I load "Astro" the file manager, it is set up to start browsing my SDCard. So I go 4 directories deep, find what I'm looking for, and do my thing. If I hit home, I go there, if I switch to another app via long-press on the home button, I go there, and things are fine. Two days later, I hit Astro again, and, because it's still running and never terminated (sure, it isn't using resources, but it remembers its previous state since it didn't exit), I'm back in the same directory I was when I left it. This is assuming I didn't reboot my phone. If I did, it would behave like I expect, taking me to my default home path. I think the biggest issue with back and exit being the "same function" is that they're not consistent across the Android experience.
ReplyDeleteNobody ever asked me to include an exit button ever for my app. And it has over 80.000 downloads and has different screens/activities. This, I think, is because the app behaves naturally for a user.
ReplyDeleteI am a strong supporter of the 'never include an exit button in your app' idea. The ONLY reason why a user (should) want this is to explicitly stop a service. For foreground services, this is natural. For background services, this means LOGOUT. Not, never ever it means EXIT, because it will not exit the app. (There really actually is no notion of exiting an app on Android.)
So please, developers, be free to implement a logout or stop service method, but no exit.
Look at fring, no exit button.
ReplyDeletehow to logout and stop him to being connected to msn/skype/irc/whatever and draining my precious battery?
you have two choices:
1. reboot
2. use a task manager
sometimes an exit button is a must
sometimes, poorly coded programs let me think that the forced monotasking imposed by apple is a good thing...
@Dandandin:
ReplyDeleteStrange... in my case, poorly coded programs make me want to look for (or perhaps write?) a better equivalent program, not consider going with a less functional platform.
I finally got my 2.1 update, and I was surprised to see that the Google Nav app has an "Exit Navigation" menu option.
ReplyDeleteIn xScope browser, pressing Back once goes to the previous page. HOLDING back brings up a menu which gives you several options ("Exit", "Clear cache then exit", "Clear everything then exit", "Cancel"). I think it's great.
ReplyDeleteDandandin,
ReplyDeleteOn Fring try: Menu -> Settings -> Exit
Dandandin,
ReplyDeleteyou might use iphone, if you are rebooting to exit Fring...
Exit button on Fring and Google Maps Navigation are to cover different things.
ReplyDeleteHere's a better explanation:
1) Regular Apps: No need of an exit button.
2) Foreground Services: They could use a "Stop Service" button (just like Google Navigation does).
3) Regular Apps with Background Services: I guess "Disable" is the right term to use in the case of Touiteur/Twidroid, and maybe, for the sake of user-friendliness, it might as well just stay as "Exit".
But, we all go back to the same. From the developer's perspective, there's still no need for an "exit" method the way everybody is used to. Only for apps that have a foreground or background service running.
In case you didn't notice, the back button in the browser goes back to the previous web page!
ReplyDeleteThis is one of the most frustrating things about Android's user experience. If I open a web address from a link posted in a tweet and subsequently click around or browse to other pages within the browser and want to go back to my twitter client (or gmail) I have 2 choices. I can hit the back button however many times it takes to eventually get there, or I can press the home key and re-launch whatever app I was originally in. Gmail doesn't like to stay in my long-press-home task switcher. This is extremely annoying. Adding a Menu -> exit function to the browser (or any apps, like music, that make use of the back button within the app) would solve that issue.
With that said I want to bring up another of your points I very much agree with, Do not presume to know how I use my phone!!!!
This article tackles the issue from a technical point of view.
ReplyDeleteThe issue is: users want the silly "exit" button, even if it does not really kill the app.
If there are other issues such as alerts, sounds etc. that the app might do, it has to take care of that on onPause() etc.
I don't see a reason to not give the user the button they want. It's a psychological issue more than technical. They are just used to it, who are we to tell them "but it's technically irrelevant!"?
This guy's own article makes the point why the user should be able to truly stop/kill/annihilate any app/process/task they want, but I'll leave that alone.
ReplyDeleteHere's why an app should include an exit button, and in fact why I think the exit button should be part of the OS "wrapper" for the app (like the x button in the corner of PC programs), forcing every app to have one: The app developer and I DISAGREE (omg!, rly?) on when the app should be running in the background. Apps that I use regularly I understand that the OS can best decide whether to allow them to persist or not, but apps that I KNOW I'M NOT GOING TO USE ANY TIME SOON or apps who's "background" features I don't particularly care for should not be forced upon me. Yes the majority of apps can run in the background and do something useful from time to time, but there are some apps, that DANGIT, SHOULDN'T BE RUNNING. Those apps are not doing anything I would consider useful, and are tying up processor cycles (even if it's for the Android's task manager to consider whether to kill them or not) and using the battery. Those are the apps I want an EXIT button for, those are the apps that should DIE!
It's like the old days of DOS and the 640k limit. These issues will become mute when we have faster and more efficient processors and memory and better batteries. Can we really expect developers to write the most efficient code and apply it in the most efficient manner? No.
ReplyDeleteIt's better to complain to someone that can really effect change, the hardware makers.
its clearly mad the operating system doesn't have a more accessible exit app function. if i hold down the home button on my android, i see the following:
ReplyDeleteSMS | Phone Portal | Email | Phone | Calendar | Camera
and it definitely bugs me that the only way to easily get them all to close is to entirely shut the phone down and start again (or use System->Apps->Manaage Apps).
There have been a few otherwise useful apps that I have removed because they use up a lot of battery life updating in the background.
ReplyDeleteI would love to have a button that does "save changes and make this app act as if it was never opened up" - I would like this as an option. Not all end users want or need to have every app working in the background, ready to leap to an updated instant life in less than a second, particularly if the downside is battery drain. A phone with a dead battery takes a lot longer than a second to open an app.
As an end user, why shouldn't I be allowed to shut your precious applications completely off??? If the Exit button in some cases only concludes an activity, and many of you are saying that because of this un-thoroughness, there should BE no exit button, then the answer from the user's point of view is that the Exit button SHOULD actually shut the damn application off!!!
ReplyDeleteDoes the phone belong to the user or to the too smart OS ? Are you telling me that it's now due time where machines - not human - should decide what to do ?
ReplyDeleteUsers are forcibly robbed off what should be theirs, and their vital peace of mind is put under the merci of someone/something else.
I think that the big problem is not the lack of an exit button, but its consequence. The absence of an exit button has caused the developers to make application to close automatically when it's in background. And this is REALLY bad, because, as and end user, I'm unable to leave some application open. For example when I'm composing an e-mail and I need to copy and paste from different source (multiple parts of an SMS or a web page). On my Symbian phone I can leave SMS, browser, and many other apps all open together, and I'm able to copy and paste text freely from these apps, without the need to reopen at every cut & paste.
ReplyDeleteAutomaitc application closing of Android is definitely a bad choice.
This is silly. As an app designer, your first devotion is to the user. If the user wants an exit button, you provide it. If they don't, you don't. The logic on how it works is irrelevant. The end user shouldn't have to know any of that.
ReplyDeleteAnd there's no reason to use the Linux clipboard model for clipboard operations. The clipboard should not need the source application to be open, nor should it blank out when you paste.
Thanks for the nice and IMHO correct explanations. I wanted to add an example regarding the useless-ness of an exit button. The app is called "DB navigator" and quite useful. Yet, if you hit the "back" button on the main screen, you will be asked "are you sure you want to exit?". After reading and understanding your post, it should be obvious to tell that it doesn't really matter whether you click "yes" or "no". The "yes" button takes you back as expected but doesn't exit anything (the application still is running). The "no" button simply lets you stay in the app.
ReplyDeleteProbably another point to your posting would be: "An exit button is useless since there is no way for an application on android to exit itself." (besides deliberately causing a FC)
i have developed an application it has lot of activities and say activity1->activity2->activity3 now i need to exit from activity3 out of the application right away how do i do this?? when i press home button my application is still running at the background :(
ReplyDeleteWell I am finishing up a finger painting app for my young kids. My wife and I both got the HTC EVO 4G and the kids frequently hit the home and/or back button accidentally when using my app or playing a game. I overrode the back button for an undo function, and sure wish I could disable the home button, so they won't exit out and roam around our phones, deleting contacts, calling 900 numbers, ordering apps or other stuff we want to prevent. In other words we need them contained in the app, with only us using a code to exit the app.
ReplyDelete"If you build an application that's predictable, configurable, and unambiguous your users won't ask for an exit button. The first time they see an unknown background Service that's been running for an hour, or the GPS icon unexpectedly starts flashing, or the device gets hot while in their pocket they're going to get narky."
ReplyDeleteNo they wont. Most users don't understand the problem and have no interest in learning. I guess most simply just blame Android, no problems like these on the iphone so it much be Android.
The Spotify app for example gets it wrong, exit button, leaves service running, does not remember its state, breaks media key functionality, stores data in the wrong location on the sdcard and so on, and it still gets high reviews on Market.
Hi appleboy, there are may ways to quit all activities you start, for example (most of these ways are bad programming but who cares ) -
ReplyDelete1. use static boolean var in the activities, say doQuit, and have a loop on separate thread monitoring this every minute. Set this attribute to true before you call onDestroy()
2. Use putExtra(boolean..) and pass it to the intent you want to close before calling onDestroy
3. use broadcastReceiver and register the activities, send doQuit before you call onDestroy
4. Use Preferences (persistent data) to pass info between activities.
5. Use Java events (probably the best option, tho Google would recommend #3)
Udi
In my case, my phone is a Motorola CLIQ running Android 2.1 (official, not modded), barely, and I do miss the Exit button that the Android browser had in 1.6. I have two reasons for wishing it there: first, because it would quickly close out all browser windows, which on a phone that is very close to the edge spec-wise is helpful. Second, because I disagree with this comment from the "Multitasking the Android Way" blog entry:
ReplyDelete"If a user later returns to an application that's been killed, Android needs a way to re-launch it in the same state as it was last seen, to preserve the "all applications are running all of the time" experience."
No. If I have exited out of my browser, I want it to return as a single window that loads the browser homepage (in my case, T-Mobile's customized Web2Go). That's what the homepage is for. Loading whatever random page I was on before isn't the experience I want. So, I will perhaps restate your "what is an exit button for" position from the start of this column:
"An unambiguous way to guarantee that an app will stop consuming resources (battery, CPU cycles, data transfer, etc), and to have it load in a default state the next time it is run." Alternatively, you could say that reloading an app in the same state it was in when it was "exited" renders the "guarantee that it was not consuming resources" ambiguous.
I liked your article, and obviously you put a lot of thought into it, and you make a very convincing argument argument.
ReplyDeleteAll of which is lost on any person, who uses Android phone with preloaded crap that comes from any major carrier.
Things you never thought you had start in the background, things you do have complain about not enough memory, the launcher shuts off to make room for a browser you left on in the background, and the magic of Android process management goes to hell in a handbasket. All because what the system thinks is critical, what it thinks is ok to shut down and what you need for the phone to be useful involve entirely different sets of priorities.
It makes you wait for launcher to reload every time you hit home key, but keeps Voice Dialer and Sprint TV at the ready, in case you want to use them, based on the usage patern. Oh, wait, but WHOSE usage patern? Since you haven't used either of the apps EVER, and loath the fact that you can't uninstall them since the moment you discovered they were generously included.
You describe the issue as it should be, and not how it is. The inclusion of an Exit button gives the user EXPLICIT control to tell the system which apps to kill, if need arises, and doesn't leave you praying for Google's or Gods divine intervention.
So, the facebook app is a good example of needing an exit button. I don't really want to "log off" because the application doesn't remember my username / password and it's hard to type it in.. I'd rather just be able to stop it from consuming resources but leave myself "logged in"
ReplyDeleteImagine for a moment, a hypothetical different world. One in which every application had several buttons in the taskbar at the top: "Minimise", "sleep" and "kill".
ReplyDelete"Minimise" would just continue running and updating in the background, but would close the UI. Like tapping the home button does now, and the back button sometimes does.
"Sleep" would stop it using any services or updates, but it would remain in memory, ready to fire up at any time, with its last state cached. Like "Exit navigation" for Google maps, and like the back button sometimes does.
"Kill" would terminate the app completely, removing it from memory, after offering to save if necessary. Like killing it with the task manager.
Apps for which it was irrelevant could disable the "run in background" option.
Now, I'm not proposing this as a solution: it's far too complex for my mum to use, which makes it bad UI design.
But, other than UI complexity, what would be *wrong* with this alternative world? What would be the downsides of putting this control in the hands of the users?
I think Google should make an EXIT option for every app which would appear always after pressing the menu button. So you could kill the whole app easily and efficiently no matter what the developers wanted.
ReplyDeleteAbsolutely not. I made an effort to make the menus appear as logical as possible, adding an extra option would ruin them.
ReplyDeleteMy pre-froyo applications DO have an exit button, but only when an exception has occurred. There's a mode in which you see only a TextView with the logo dimmed in the background. The contents of the TextView has some explanation of what happened and the exception with the backtrace. The menu then has only 2 options: Send and Exit. The send option starts an ACTION_SEND intent to a support address and exit really does end the process, just to make the user feel less frustrated.
Thank you for a very good article and many enlightened comments.
ReplyDeleteI'm not against not having an exit option but this almost constant decrying of having an Exit/Quit function in Android Apps sometimes feels like a religious dogma - 11th Commandment - "Though shalt not have a Quit option in Android Apps because God Google forbids it". Yet, its not forbidden and is even documented in the Android developer docs. If one follows the correct procedures with good coding then a safe Quit function is easy to implement.
Many users expect one and many posters above have given very good reason why an app might need one. By the way, Goggle's own Android SDK, Basic4Android and HyperNext Android Creator all offer quit options.
One last point - CoPilot for Android has an exit button that clears Copilot from memory and releases the resources it was using.
No leí más que los primeros post, están muy burros.... Google no le va a poner un botón de Exit a sus cosas, aunque varias SI lo incluyen, por la sencilla razón que eso es lo que trae el telefono y que el proceso wiper se encarga de administrar esos asuntos... Y eso que apenas estoy haciendo mi primer App...
ReplyDeleteActually my biggest gripe with Android is not having an option to actually close certain apps. For example. I access several HTTPS type websites on my phone and they require logins. So here is the problem.
ReplyDeleteLets say I go to cnn.com first, then nfl.com, then I access a secure site that requires a password.
After Im done accessing a secure site if hit the back button it takes me to the screen that says the info has to be resubmitted ok, or cancel doesnt matter which button I hit I get caught in a loop of the same page refreshing. So what I have to do and have done on every android phone I have had is Open a second window then view all windows actually click the exit button on the window i cant close, and the new window i just opened hit the back button to exit it.
Its stupid not to include something like hitting back button 4 times in a row should just force close the app. I hate having to hit the back button 10 times if I went to 10 different websites before i decide to close the browser. Just doesnt make sense.
Great post . I should think it's very useful for everyone who want to create a good Android application.
ReplyDeleteWe really need the EXIT button because of all that pre-installed crap wich i cannot delete from the phone.
ReplyDeleteAs an example, the flashlight always starts a background service in every 5 minutes or so. I really would like to disable it completly but heck, i cannot even uninstall it.
I think we, the users, need to have more control here. I love having a lot of apps but I hate how every one of them can controll my phone and I cannot do somthing to stop this.
Here's my point of view as an Android developer and user who also codes extensively on Linux and Windows. While some simple apps might not need an exit button, most complex apps do. It is the cleanest way to convey to the user what's really happening. Due to the wide variety of implementations nobody is really sure what an app does the last time you press its back button. Especially with browsers or apps with multiple activities having to press back 8 times to get out of the app is counter-intuitive and bad GUI design.
ReplyDeleteI have two apps on the market, both of which deserve an exit button. One is a streaming music player with no real concept of pausing the music (this is determined at the server side), and the other can perform a CPU-heavy computation in the background. In both cases my users need a definite way to be sure the app is no longer using their phone's resources.
Developers should ensure that, if they provide an exit button, it is *not* the same as the back button or simply calling activity finish. It should be a true exit, for example
System.runFinalizersOnExit(true);
System.exit(0);
Before I understood how Android apps work, I drove to a client demo with the help of the Android navigator on a tablet. We brought the tablet in to the demo and during the demo, the navigator started talking. That was kind of funny. Then I got the tablet, pressed the menu button to get rid of the navigator, then pressed the off (i.e. standby) button on the tablet. I was sure that would work but 2 minutes later it started talking again. Which was a bit embarassing. Then I just turned the thing totally off. But this is what happens when you don't provide users with an obvious exit button, and when the users haven't learned how your platform is meant to work yet. (Now I know about the exit navigation button, but don't try and tell me it's in an obvious place. It's basically the third-most-important function).
ReplyDeleteArticles like this bring me great pain. They assume the following:
ReplyDelete1. Android is perfect and doesn't make mistakes. This is clearly NOT true. The comments mention poorly behaved apps. How about poorly behaved OS's? Most phone users never get upgrades or fixes to these problems because of vendor lock in.
2. Android can tell when your phone/device is running poorly. This is also not true. Android looks specifically at memory management as its sole guide for determining performance. Unfortunately, total amount of memory left is a very poor guide for how well your phone is working. I can write an app that brings the whole device to its knees while not using a drop of memory.
3. Developers are smarter than users. This one really pushes my buttons. As a fellow developer I have seen this time and time again. Developers looking down their noses at users with the belief that users are stupid and couldn't possibly know what they want. Well... I'm a user too and having an exit button on a game that I don't intend to use for the next three weeks is a benefit. And not because I'm overly concerned about resources per se.
4. Android knows more about what its users want than the user themselves. Again, this is preposterous. The idea that Android can read my mind and that I should bend my desires to fit Android's ridiculous lifecycle model is absurd.
People complain about Android all the time. It's no wonder the iPhone is ruling the roost. Until Google and its multitude of yes-men realize that users are in control, Android will continue to lag behind. If a user wants an exit button (and yes, there are many logical reasons to have one), then the OS should give them one. It is insane for an OS to think it can dictate the user's desires for them.
Took me a bit to wrap my head around how this all works, so I tested it.
ReplyDeleteIt's awesome. Hit the "Home" button when you want to leave any app. Assuming the app is correctly designed (and does not require background activity when you are not using it), it is no longer running. Android takes a "snapshot" to cache of where the app was. Other than that, bam, the app is not consuming your precious resources.
The best part though, is when you need the app again - blamo, it resumes right where it left off, as if it never stopped running! Brilliant.
As an "end user" and not a self-righteous techy who wants to dictate to everybody, I think all phones should have a physical kill (close) button on the side to close the current app or process and return to home page, regardless of what that process may be - internet, camera, anything. I'm sick of opening the calendar or memo and finding the last page viewed instead of a generic start page. Older phones just had an off button for any process - now you have to tap back-back-back-back to end - is that really progress? Of course not.
ReplyDeleteRight ...
ReplyDeleteand even in skype-like applications, you can manage disconnection/reconnection with a good timeout/onPause/onResume management.
If your users ask for an exit button it should work same as the home or back button (without them knowing that if you want) and it's up to the developper to do that.
Even on an OS like Win7 when you close an app, the system keep some things in memory (without the user's knowledge of it) so that if you restart the application it will be quicker. And if Win7 needs the memory it clear things as needed.
I really don't agree with this article.
ReplyDeleteAs a user, I want to be able to control when and if an app still runs and when it exits.
Lots of games and apps have states I need to save before they exit, like a really long level I worked for half an hour to complete and then two minutes before finishing it a phone call comes along and destroys my work ...
IGO has an exit button, for example, and I really prefer that than other android apps that just exit when I hit the home button.
When to Include an Exit Button in Android Apps (Hint: Never)
ReplyDeleteYou are an complete idiot and infantile. Facebook app will consume ram memory while running in background.
An exit button IS A MUST for a phone browser! Especially when the user is watching porn.